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Introduction 



Nouvelles possibilites avec le modele objet-relationnel : 

• definition de nouveaux types complexes avec fonctions de manipulation 

• une colonne peut contenir une collection : liste, ensemble, • • • 

• ligne consideree comme un objet avec un identificateur OID 

• utilisation de references aux objets 

• extension de SQL : SQL3 (ou SQL99) recherche et manipulation des 
donnees 

Inconvenients du modele objet-relationnel : 

• ne s'appuie pas sur une theorie solide comme le modele relationnel 

• pas de standardisation : implantations differentes, partielles dans les SGBD 
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Le modele navigationnel 

Objectifs 

Faciliter le passage vers I'Objet par un ensemble de regies de transposition : 
Diagramme de classe-UML => navigationnel => Objet 

Favoriser la visualisation des structures complexes et des chemins de 
navigation possibles en conservant la notion d 'objet. 

Representer concretement le plus de contraintes possibles pouvant etre 
specifiees par le langage DDL du SGBD. 

> Lacune du Mnav : 

- Ne represente pas bien le partage des types entre differentes parties du 
modele UML (classes). 

- Devient rapidement encombre et encombrant pour des modeles complexes! 



Pourquoi le navigationnel? Le modele introduit les liens logiques de type REF 
(implementation de la REF est toujours indeterminee au niveau conceptuel). 

Les references (Ref ou REF) facilitent la navigation entre les objets). Les contraintes au 
niveau de la reference peut etre specifiee dans le modele. 



O.Lamouchi 



Le modele navigationnel 



La classe UML sera rendue dans le Mnav par une classe dite externe qui est 
en quelque sorte au plan informatique un type (i.e. une structure nominee) 
defini par ses attributs. 

Une classe externe definit des objets autonomes (dont I'existence ne depend 
pas d'un autre objet) dans la base i.e. possede une valeur + un oid 

Un oid est un identifiant d'objet interne et unique, non reutilisable pour toute la 
vie de la base. Un objet ayant un oid est persistant dans la base. 

Les attributs du modele Mnav sont simples ou complexes. 

Attribut simple: 

L'attribut simple est idem a celui de UML: type atomique avec ses operations 
primitives regulieres et implicites: 

Exemple: un entier avec ses operateurs arithmetiques, une chaine avec son 
operateur de concatenation, ... 
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Le modele navigationnel 



Attribut associe a un seul objet: 

Un attribut associe a un seul objet d'une classe est represents par un lien 
interne avec un lien monovalue vers une classe interne. 




Employe: 


nasE : int 
nomE : str 
specialite: 


ing — 




spec: string 

a n neeNQate ^ _ _. 







Classe interns nominee 
et dotae crune Interface 



Dans cet exemple, l'attribut specialite est obligatoirement value par un objet qui caracterise 
chaque Employe et est imbrique dans la classe externe Employe. Cet objet a une interface et 
une persistance. 



Le modele navigationnel 



Attribut complexe: 

L'attribut complexe permet d'abandonner la FN1 en ajoutant une structure de 
tuple pour regrouper plusieurs attributs . 

Le tuple est une structure logique lineaire formee d'attributs heterogenes ou 
pas, simples ou complexes, sans interface. 

Un attribut complexe definit des valeurs dont I'existence depend que de 
I'objet externe qui I'heberge. II est represents par une structure non nominee 
et sans interface. Ce n'est pas une classe interne mais uniquement une 
structure pour y ranger des valeurs. 



Exemple d'un attribut de 
type complexe rendu par un lien 
Interne simple referant a une 
structure de tuple. 



Employe; 



nasE : int 
nomE : string 
special te • 



;t un tuple el r* 
se interna. 



Un employe a une 
specialite definie par 
3 attributs 



L'attribut « specialite » est associe a une structure de tuple. 



Le modele navigationnel 



Attribut d'ensemble ordonne: 

Un attribut d'ensemble ordonne est rendu par un lien interne simple vers une 
structure de type varray. 



Employe: 


nasE : ii 
nomE : 
lesSpec 

c 


it 

string 

alitesj#_, 

r --- — t ■ 


----- 


srrhr; 




string 


string 







Classe interne de type 
ensemble rendue par un 
type varray 



Les elements de l'attribut lesSpecialites sont stockes dans un varray (similaire a un tableau 
ou un array). Chaque entree est indexee et peut-etre soit une valeur soit un objet interne. Le 
varray a des procedures propres dites attributs. 
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Le modele navigationnel 



Attribut d'ensemble non ordonne: 

Un attribut d'ensemble est rendu par un lien interne multiple vers un 
ensemble d'objets d'une classe interne. 



Employe: 


nasE : int 
nomE : str 
lesSpecia 


ing 

ites: m — j 


spec: string 

nomS : string K 







Classe interne dotee 
d'une interface 



Les elements de /'attribut lesSpecialites sont des objets de la classe interne pouvant etre 
simples ou complexes imbriques (ou pas) dans la classe externe Employe. 



Du diagramme de classes vers le modele navigationnel 



Transformation des associations 0..1-1..1: 



CI 


0.1 <A 1,1 


C2 


as1 


as2 


Asso 


op1 


op2 



lere solution : 

L'attribut de type Ref peut etre nul dans C2, L acces privilege est par C2. 



CI 




CI 


asl 


as2 
081*2 











Toutes les multiplicites de 
la classe UML ne sont pas 
representees parce Mnav! 



En lisant l'attribut ar2 de C2 (1 ref ) il y a un acces direct a I'in stance correspondante dans 
CI . Le ar2 est de type REF et peut etre null. 
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Du DC-UML vers le navigationnel: 
regies de passage 

Transformation d'une classe UML : 

Chaque classe du DC-UML, sauf les classes-associations, est transformee en 
une classe externe du Mnav. 

Chaque attribut compose de type tuple UML devient une classe interne avec 
un lien interne simple (une seule occurrence) 

Chaque attribut d'ensemble est rendu par un lien interne multiple ou un lien 

externe multiple (avec Ref) selon I'existence autonome ou pas des objets au 
regard de la suppression. Le choix est aussi fonction de la performance 
d 'acces recherchee. 

Identifiant facultatif pour la classe du Mnav: 

■ Chaque classe du Mnav (sauf les sous-classes dans I'arbre d'heritage) et la 
classe d 1 association, peuvent avoir un identifiant de valeur. Souvent 
pratique pour la recherche, mais non obligatoire. 

■ Si aucun attribut ne convient pas comme cle, on peut ajouter une cle, si 
possible significative. Ce n'est cependant pas une exigence du modele. 
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Du diagramme de classes vers le modele navigationnel 



O Transformation des associations 0..1-1..1: (Suite) 

2eme solution avec le parcours inverse : acces via C1 et acces a C2 via l'attribut 
de reference ar1 qui ne peut pas etre nul. 



C1 


0..1 


C2 


as1 


as2 


A> 


op1 


op2 



La multiplicity du cote 
de CI n'est pas 
representee ! 



C1 




C2 


as1 
ar1 q 


as2 









Le sens de la navigation est indique dans le DC-UML suggerant la transformation appropriee. 

Si le sens de la navigation est absent dans I association : on peut assumer alors que les 2 
sens sont equi probables 



Du diagramme de classes vers le modele navigationnel 



Transformation des associations 0..1-1..1: (Suite) 
3e solution pour les 2 sens de parcours: 2 liens simples (aucun sens privilegie) 



C1 



as1 
ar1 



C2 



as2 



-O ar2 



ar1 de C1 est du type REF monovalue non null qui refere a C2 (done aux objets 
de la classe C2). 

ar2 : est un attribut REF qui refere a un objet de C1 et qui peut etre nul l. 
La suppression de C2 et 1 mise a jour de ar1 . 
La suppression de C1 est suivie d'une mise a jour de ar2 

Ce Mnav exprime le nenforce merit des 2 contraintes par le modele sans egard au sens privil egie du 
parcours de ' association. 



Du diagramme de classes vers le modele navigationnel 



Transformation des associations 0-1-1-1: Exemole 
Stages etudiants (UML) : 



Etydiant(e} 


q ^ Effectu© > 1 ^ 


Stage 


matricule' ; string 
riom : string 


noS* : int 

the me S: string 

respS : string 





Solution avec une ref simple: 



Etudiant(e): 




Stage: 


matricule* : string 
ram : string 


noS* : int 
themeS: string 
respS : string 


refStage 0 


► 



Un lien peut etre parcouru par la reference : avec la notation pointee. 



Du diagramme de classes vers le modele navigationnel 



Transformation des associations 0-1-1-1: (Suite) 

4e solution (dite universelle): utilisation d'une 3e classe CA avec 2 liens externes. 
Toutes les multiplicites sont renforcees par le modele. 



C1 



as1* 



C2 

as2* 



CA 



^ar2 
aM 



Evolution du modele: 

Le modele peut evoluer en integrant un attribut pour la classe d'association sans penaliser 
/'interrogation et la manipulation de la base d "objets. 
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Du diagramme de classes vers le modele navigationnel 



Association de multiplicites 0..* et 1-1 

(enfants) (parent) 



C1 


0..* 1.1 


C2 


as1* 


as2* 


<A 


op1 


op2 



as : attribut simple 
ar attribut de type REF 
op: interface 



1ere solution : un lien multiple. La multiplicite minimale 0 figure a la source du 
lien ar2 de C2. Le parcours privilegie est pris en compte. 



C1 

as1* 



op1 



C2 



(<) 



as2* 



op2 
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Du diagramme de classes vers le modele navigationnel 

Association de multiplicites 0..* et 
2e solution : un lien multiple et un lien simple externe inverse. 



C1 




C2 




as2* 
as3 
-0 ar2 


an — 






ar2 lien multiple done ensemble de references sur C1 (eventuellement vide) . 
ar1 est un attribut de type Ref qui reference un objet de C2. (toujours value) 

La suppression d'un objet de C2 doit entrainer les objets de C1 associes. 

La suppression d'un objet C1? C1 disparait et sa ref supprimee via le lien ar2. 



Du diagramme de classes vers le modele navigationnel 



Association de multiplicites 0..* et 

4e solution : (universelle, sans parcours privilegie): utilisation d'une troisieme 
classe. Cette classe porte le nom de I'association et contient deux liens simples 
pour implementer I'association. 




Sans les liens supplementaires vers CA, la navigation (done /'accessibility ne serait possible 
qu 'a partir de CA. Cette solution fournit un Mnav plus lourd a gerer! La suppression de C2 
peut impliquer plusieurs changements: suppression dans CA et dans C1. 
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Du diagramme de classes vers le modele navigationnel 



Association de multiplicites 0..* et 
3e solution : un lien monovalue non nul vers le parent C2 



CI 




C2 


as1* 

ar1 ^ 


as2* 









Chaque instance de C1 est liee a une instance de C2 par la reference ar1 obligatoire. 
La suppression de C1 se limite a cette operation. 

La suppression de C2 doit etre bloquee si elle est referee par un objet de C1 . La source 
du lien ar1 doit avoir obligatoirement une reference valide. 

La suppression de C2 devrait done eventuellement entrainer aussi celle de C1 qui s'y 
refere et cela au cours d'une meme transaction. 



Du diagramme de classes vers le modele navigationnel 



Association de multiplicites 0..* et avec un lien interne multiple 

Autre modele legerement different. 

En supprimant un objet C2, 
les objets C1 associes sont aussi supprimes. 

L'ajout d'un objet de C1 suppose I'existence 
d'un objet note C2. 



Le lien interne et multiple pour ar2 sous-tend un ensemble forme avec des objets- colonnes 
de type C1 imbriques. La realisation physique en Oracle prend la forme d'une sous-table 
d'objets. 

L'acces est privilegie par C2 pour trouver les C1. La suppression de C1 n'entraine pas celle 
de C2, la classe note. 
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Du diagramme de classes vers le modele navigationnel 



Association de multiplicites 0..* et 1..1: Exemple 



Coups: 



noC* : int 
titreC : string 
nbCred : int 
refProf < 



Cours: 


1„* Enseigne 1.1 


Prof: 


noC* : int 
titreC :string 
nbCred : int 


noP*:int 
nomP : 
gradeP:int 





Prof: 



noP* : int 
nomP : string 
gradeP : int 
lesCours f 



Quelles sont les contraintes du Mnav pour I'ajout et la suppression d'un cours? 



Du diagramme de classes vers le modele navigationnel 



Association 0..* et 1..* sans attributs d'association 



Cours 




Etudiant 


noC* : int 


0 * Inscrit 1* 


matricule* 


titreC: string 




norm: string 


nbCred : int 







Sans preference de parcours: deux liens multiples avec deux nouveaux attributs 
de type REF . Une redondance de liens qui rend cependant la gestion plus lourde! 



Cours: coursj 




Etudiant: 


noC* : int 
titreC : string 
nbCred : int 
lesEludlarrts • 


matricule* : int 
nom : string 




lesCours 0 











Suppression d'un etudiant : danger d'incoherence avec I'oubli de la mise a jour de I'attribut 
lesEtudiants. L'application doit prendre a sa charge cette derniere mise a jour. 
- En suppression d'un cours ? Idem 
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Du diagramme de classes vers le modele navigationnel 
Association de multiplicites 0..* et 1..1: Exemple 

Quelles sont les contraintes associees a I'ajout et a la suppression d'un cours / 
prof? 

A I'ajout d'un cours: 

Le cours ajoute doit etre associe a un prof par une reference obligatoire. 
A la suppression d'un cours: 

Le cours est supprime. 

II doit etre aussi supprime de la liste des refs du prof concerne. 
A I'ajout d'un professeur: 

Cela implique I'ajout d'un ou plusieurs cours (contrainte de multiplicite). 
A la suppression d'un professeur: 

- suppression des cours enseignes par ce prof. 

et - suppression du prof. 

Ces contraintes devront etre implementees dans une methode de suppression qui 
prendra en charge la verification de ces contraintes dans une meme transaction. 
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Du diagramme de classes vers le modele navigationnel 



Association 0..* et 0..* avec attributs a la classe-association 
1ere solution: (universelle) : une 3e classe avec le nom de I 'association est 
formee avec les attributs de I 'association, deux liens monovalues vers les classes 
participantes. 



C1 



si* 



C.7 



as2» 



CA12 



as3 



■ to pricvi de la clsssc ::';'. : :r 



Le CA1 2 peut avoir un identifiant compose de as1 
et as2 represents dans le CA12. 



CA13: 



as3 
»ar3 
ar4 #- 



C2; 



as2* 



Un objet de C2 (:C2) non associe a un objetde C1 n'aura pas 
d'objet d'association du type CA12. 



Du diagramme de classes vers le modele navigationnel 
Association 0..* et 0..* avec attributs a la classe-association 



C1: 



CA12: 



as3 
ar4 < 



C2: 



as2* 



Quels sont las C 1 associes a une 
valeurcle k2 de C2? -ajoutez la 
valeur de as3 

1- recherche dans CA12 
Select o.ar3.*, o.as3 
From CA1 2 o 
Where o.ar4.as2 = k2 



Quels sent les C1 non associes a un 
objet C2? 

2- Les C1 moins les CA12: 
Select x * From C1 
— (moins) 
Select o.ar3* 
FramCA12 o 
Where o.ar3 is not null; 



Du diagramme de classes vers le modele navigationnel 



Association 0..* et 0..* avec attributs a la classe-association: Exemple 





Departement: 


0..* 0..* 


Log I del: 






codeD*: int 


codeLog*:int 






1 






nomD: string 




nomLog:string 





Achat: 



date Achat: 



Departement: 




Loaiciel: 




codeD*: int 
nomD: varchar 




codeLog* : int 
nomLog : varchar 
les Achats - 




A 


Achat :actiat_t 

dateAchat : string 

• refDep 















Les achats de logiciels distincts faits par un departement sont representes par la classe 
interne dont les elements ont la structure achatj 
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Du diagramme de classes vers le modele navigationnel 



Association 0..* et 0..* avec attributs a la classe-association 

2e solution: une classe interne avec un lien interne multiple et un lien externe 
simple. 



C1 



as1* 



C2 



as2* 

ar2 q_ 



CA12 



as12 
ar4: 



La suppression d'une instance de C1 implique la suppression de /'instance de CA12 
associee. 



Du diagramme de classes vers le modele navigationnel 



Exemple:Modelisation des randonnees effectuees par des personnes qui visitent 





Rando: 




Personne: 


UML 




noR' : int 


0.. * 




nasP*: In* 



Tant que les classes Mnav sont 
con creti sees par des classes 
d'objets dotes d'un oid, la cle 
prima ire n'est pas essentielle, mais 
utile pour la recherche des objets. 



RandoPerso; 



lieuDepart: 
datePepart: 



lleuT*:strfng 
regionT: 



\7 



dateVisrte: 
prlx: :real 



Mnav 



RandoPerso: 



lieuDepart: 
date Depart: 
-40refRando 





LieuTourist: 




IteuT: string 


RL: 


region!": char 


d ate Vi site: Date 




prlx: real 


I 


refLleuTourtet £ 




lirefRandoPerso 
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Du diagramme de classes vers le modele navigationnel 



Exemple: (suite) 

Dans le choix de la transformation, il ne faut pas perdre de vue I'exploitation 
subsequente du modele. Cela peut justifier la classe d'association. 

Voici quelques clauses SQL pour interroger cette base: 

Quels sont les regions de depart pour les randos effectues par le randonneur 
dont le nasP est 3456? 

SELECT rp.refRando.noR 

FROM RandoPerso rp 

WHERE rp.refPersonne.nasP = 3456; 

Quels sont les lieux touristiques visites par le randonneur dont le nasP est 
3456? 

SELECT t.refLieuTourist.lieuT 
FROM RL t 

WHERE t.ref RandoPerso. ref Personne . nasP = 3456; 
— double indirection 
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Du diagramme de classes vers le modele navigationnel 



Les choix a privilegier pour les associations 



Pour ('association 


Modele navigationnel 


1.-1 — 1-1 


Un lien monovalue obligatoire 


1 ..1 — Q..*{sans preference de navigation} 


Un lien monovalue de enfant vers le 
parent 


0..* - 1..* sans attributs 


2 liens multiples 


0..* - 1..* avec attributs 


2 liens mono + CA 



Les contraintes non exprimees par le Mnav seront renforcees par les methodes ou par 
les clauses DDL propres au DDL objet. 



